home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 1165 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.5 KB
  1. From: kuehl@uzwil.informatik.uni-konstanz.de (Dietmar Kuehl)
  2. Message-ID: <4l60m4$5n8@news.BelWue.DE>
  3. X-Original-Date: 18 Apr 1996 18:12:20 GMT
  4. Path: in2.uu.net!bounce-back
  5. Date: 19 Apr 96 14:48:02 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: auto_ptr problem?: delete or delete[]
  9. Organization: Fakultdt f|r Mathematik und Informatik
  10. References: <199604181455.QAA12877@bredex.bredex.de>
  11. Reply-To: dietmar.kuehl@uni-konstanz.de
  12. X-Newsreader: TIN [version 1.2 PL2]
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBFAgUBMXenveEDnX0m9pzZAQGoyAF/fpH8Q8aXgY8QcA67EAlTIJip0n5EBJXM
  15.     aQZnVhSiUShj/4REoqHD1xF0qYGMNhqD
  16.     =verm
  17.  
  18. Hi,
  19.  
  20. Nico Josuttis (nico@bredex.de) wrote:
  21. : In a tutorial a student asked a very good question i think:
  22. : How can auto_ptr imagine which delete to use.
  23.  
  24. This is simple: 'auto_ptr' is to be used for non-array objects only.
  25. The requirements for the pointer 'p' stored in an 'auto_ptr' is, that
  26. you can apply 'delete p' (see lib.auto.ptr.cons).
  27.  
  28. : Consider:
  29. :  int* p = new int;
  30. : and
  31. :  int* p = new int[10];
  32. : should result in different delete operations.
  33. : But if I let auto_ptr do the job, how does it know
  34. : which one to use?
  35.  
  36. It knows because you are supposed to guarantee that you don't store a
  37. pointer to an array object in the 'auto_ptr'.
  38.  
  39. : Isn't it a BIG design problem ?
  40.  
  41. Not really. You are not supposed to do many allocations of array
  42. objects anyway: Use 'vector' instead. It is, however, a security
  43. problem: A user might get trapped into the idea that an 'auto_ptr' can
  44. be used for both array and non-array object. Especially, as there is no
  45. equivalent for array objects (e.g. 'auto_array_ptr'). BTW, note that
  46. the access methods for 'auto_ptr' are not very well suited to be used
  47. for arrays:  E.g. the subscript operator is missing rendering the use
  48. of 'auto_ptr' for array objects useless.
  49.  
  50. : Reading the DWP it calls delete (without [])
  51. : what would be wrong in many cases since
  52. : using new for arrays is probaly made very often.
  53.  
  54. Probably not, as there are several aspects which render newing built-in
  55. arrays as quite dangerous. A much better alternative is using 'vector'
  56. (or some other array class where 'vector' is not suitable).
  57.  
  58. : I fear we need two kind of auto_ptr, don't we?
  59.  
  60. If there are more than one kind of 'auto_ptr' I insist on having at
  61. least four kinds of 'auto_ptr', i.e. for
  62.  
  63.   - non-array objects allocated with 'new T(...)'
  64.   - array objects allocated with 'new T[]'
  65.   - raw memory objects allocated with 'operator new()'
  66.   - raw memory array objects allocated with 'operator new[]()'
  67.  
  68. I guess there are much more. You might want to have a look at the
  69. article I wrote to the thread "auto_ptr problems" in
  70. comp.lang.c++.moderated: There I present an implementation of
  71. 'auto_ptr' which makes use of a framework where both the resources to
  72. be managed (the pointer types I mentioned above plus resources like
  73. files, locks, windows, etc.) and the style of the management (like for
  74. 'auto_ptr', reference counting, and other styles) can be varied
  75. independently.
  76. --
  77. dietmar.kuehl@uni-konstanz.de
  78. http://www.informatik.uni-konstanz.de/~kuehl/
  79. I am a realistic optimist - that's why I appear to be slightly pessimistic
  80. ---
  81. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  82. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  83. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  84. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  85. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  86.